View all comments

This PR changes the #[type_const] attribute to the type const syntax for #132980.

This will fixes #151273 and similar issues, since we need to check type const of items before expansion. The move to add a syntax was mentioned here: #151289 (comment)

The first part of this PR adds support by allowing type const <IDENT>: <TYPE> { = <EXPR> }; syntax in rustc_parse/src/parser/item.rs.

The next part since the AST item does not contain enough information to determine if we have a type const was rework ConstItemRhs into ConstItemRhsKind to store the information since we no longer have the attribute acting as a source of extra data/metadata.

The hir node ConstItemRhsKind current shape mostly works, except in the case of TraitItemKind where it is an option. I initially went about giving hir::ConstItemRhsKind a similar form the AST, but it touches a lot more lines of code and files so because of that, the less invasive option was to add a simple boolean flag to TraitItemKind.

The forth part of this PR includes adding a query I called is_rhs_type_const so that we can handle both local and foreign def_ids.

The fifth aspect of the PR is adding a mgca_type_const_syntax feature gate that is checked before expansion. The standard mgca feature gate is ran after expansion. This feature gate allows for conditional compilation (e.g #[cfg(..)]) of the type const syntax in nightly without min_generic_const_args being enabled.

The last bit is updating all the the tests that used the #[type_const] attribute to use the new syntax that failed because of the changes. This is the bulk of touched/edited files in the PR.

r? @BoxyUwU
@rustbot label +F-associated_const_equality +F-min_generic_const_args